Client bridges (CB) are used to connect a wired communication network (e.g. Ethernet) to a wireless communication network (e.g. IEEE 802.11). A problem to be addressed by client bridges is to make wired clients on the Ethernet side of the CB appear as wireless IEEE 802.11 clients, each associated to an access point across the IEEE 802.11 air interface. To accomplish this, the CB needs to transmit and receive wireless packets on its wireless IEEE 802.11 radio on behalf of each of their wired clients. This includes returning Acknowledgment (ACK) messages of various types within the limits specified by IEEE 802.11n when an IEEE 802.11 packet is received.
Current IEEE 802.11 radios implement Acknowledgements (ACK), Block-Acknowledgements (BLOCK-ACK), and Clear-To-Send (CTS) Indications in hardware (i.e. a hardware radio register), because doing it in software is infeasible owing to tight time constraints needed for this messaging. Specifically, BLOCK-ACKs require that a bitmap be generated for every single received packet in an Aggregated MAC Protocol Data Unit (AMPDU) aggregate frame. This can be time-consuming and easily exceed the nine-microsecond acknowledge response time mandated by IEEE 802.11. Moreover, hardware implementations only acknowledge packets whose destination Media Access Control (MAC) address has been pre-programmed. Further, these implementations can only accept one MAC address at a time, or MAC addresses that are contiguous in some IEEE 802.11 configurations. However, contiguous addressing would require address translation on the MAC addresses to map to a block of contiguous addresses. There are two problems with this: (1) the address block being translated to, has to be managed carefully so as to not cause conflicts with other address blocks, which means additional overhead of address coordination across different client bridges, and (2) proprietary layer-2 protocols that rely on the MAC address being the same as the external MAC address will not work correctly, which could be resolved by a reverse-translation on the AP, but that would mean that both the CB and a modified access point would need to agree on a translation mechanism using a control protocol of some sort, which is not available to all CB systems.
These limitations makes client bridges very difficult to implement, since client bridges cannot use the radio hardware to acknowledge packets for several different wired MAC addresses since it can only use the radio hardware to ACK one of these MAC addresses and generate the rest of the ACK messages in software. However, generating IEEE 802.11 ACK, BLOCK-ACK, and CTS messaging in software will considerably impact packet-bridging performance of the CB, rendering the CB very slow for even average size deployments, unless a very powerful CPU is used in the CB, which increases its cost prohibitively.
What is needed is a technique for a client bridge to reliably serve the needs of a plurality of wired client MAC addresses communicating with a wireless 802.11 network. Also, it would be of benefit for the radio hardware of the client bridge to generate real time responses to incoming radio packets.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.